Thanks I'll take a look next week.

@erasche Finally had a chance to look at this.

I'm confused. Is the implication that I'm to bring in #18 (which is fine). I want to provide something where a user (any user) can continue to go in and mess with the docker file if need be.

I like the idea of users connecting with a mounted volume. While we have users providing solutions to a larger user-base (like yourself), which are better than what I am providing, we also have users providing a server for a lab for a month and want something that can load up quickly and be used for a month and then tossed. I think I have in #18 works really well for that.

I think we just need to sync up. My guess is what you have for the minimal case is what we want moving forward (for the minimal case), but we're going to want a few more versions for some of our other users.

We might just need to touch bases on gitter when you have a moment.

I'm confused. Is the implication that I'm to bring in #18 (which is fine).

This should address everything in 17/18, those should be closed/not merged with this PR.

I want to provide something where a user (any user) can continue to go in and mess with the docker file if need be.

Is that what your end users are asking for? What sort of modifications are they asking to make?

• Apollo core code changes: should not be done in the container, they will lose their work, they will be unhappy. This is not the place to develop apollo. Most users making code changes want to use their IDE, it is simple enough to say "fork on github, make change, point this dockerfile at your own git repo". Very few projects do this in my experience, none of the big ones.
• Plugin changes: very few people run as many organisms as we do (and if they do, they're big time admins), so it's easier for them to continue to add them to their existing JBrowse confs.
• What docker changes are you imagining? I'm probably not aware of use cases outside what we worked on.

Here are the target users that I can imagine, but my imagination may be limited. Personally, I think there is little intersection between the following user groups:

I like the idea of users connecting with a mounted volume.

This is possible here.

While we have users providing solutions to a larger user-base (like yourself), which are better than what I am providing, we also have users providing a server for a lab for a month and want something that can load up quickly and be used for a month and then tossed. I think I have in #18 works really well for that.

This is a huge part of my argument for the base image without code in it, rather than a unified image.

If you're targeting labs who want to set it up for a month, they should be using the docker-compose version which is way easier to set up than knowing how to invoke the unified image with the directories in the right place. Using the unified you have to copy an ugly command line and it's hard to see what's going on since you get the logs from one service (apollo) and none of the others.

If they had started out with docker-compose, they would be able to separately see and run commands within each container. Here's an example of how their life is qualitatively better:

I think we just need to sync up. My guess is what you have for the minimal case is what we want moving forward (for the minimal case), but we're going to want a few more versions for some of our other users.

This is the non-minimal case in this branch, hence my surprise at these comments.

We might just need to touch bases on gitter when you have a moment.

If it's ok with you, I'd prefer to have the discussion here as long term documentation for rationale behind decision making.

Thanks @erasche very thorough. This is looking awesome (now that I understand it). To summarize what I wrote below.

• add a link in the docker file to the root source (even if its in a branch)
• add awesome table with commands and use-cases (esp. as it includes mounting the database)
• add missing docker-compose file?

=== Details below ===

I'm just going to comment on places where I have questions / comments. Otherwise assume that I agree:

What docker changes are you imagining? I'm probably not aware of use cases outside what we worked on.

I want something where they can look at how the image is generated so that they can make their own modifications or at least understand what is going on. Was hoping that could be here for each branch.

Of course, if its just this: https://github.com/GMOD/docker-apollo/tree/unified that is fine. Just link to the source somewhere (maybe above the "from" in the Dockerfile, even if its obvious now. Can be https://). Wasn't sure if that was done yet or not.

# https://github.com/gmod/docker-apollo/tree/<branch>
# quay.io/gmod/docker-apollo:<branch> 

If you have a better idea that's fine.

I like your user run-down and I think I understand the PR better now and it all makes sense.

If they had started out with docker-compose, they would be able to separately see and run commands within each container. Here's an example of how their life is qualitatively better:

You should put this awesome table in the doc if possible. Even the other one wouldn't hurt.

My only caveat is that I don't see a docker compose file. Was there supposed to be one for docker-apollo, or were they supposed to create their own file or use another repo?

If it's ok with you, I'd prefer to have the discussion here as long term documentation for rationale behind decision making.

That's fine.

There are a ton of advantages of this PR over what is there. I kind of want to move it into its own repo, though.